I understand the benefit of tracking packet loss on a smaller time scale, but I'm worried that a frame is too small a scale. I don't think we see enough packets per frame to gather a good metric of packet loss on the network. For example, if 10 packets are received per frame (which would be a consequent volume of traffic), then packet loss can't be lower than 10% for any frame. Users are only likely to see long periods of 0% packet loss, interspersed with spikes of 10%-20%. That's not practical to figure out packet loss on the network, since you then have to count the total number of frames between these spikes (e.g. a 10% spike every 10 frame means 1% packet loss on the network, which is a more realistic and useful figure). I think tracking packet loss over periods of say a second might be more useful and accurate.

I understand the benefit of tracking packet loss on a smaller time scale, but I'm worried that a frame is too small a scale. I don't think we see enough packets per frame to gather a good metric of packet loss on the network. For example, if 10 packets are received per frame (which would be a consequent volume of traffic), then packet loss can't be lower than 10% for any frame. Users are only likely to see long periods of 0% packet loss, interspersed with spikes of 10%-20%. That's not practical to figure out packet loss on the network, since you then have to count the total number of frames between these spikes (e.g. a 10% spike every 10 frame means 1% packet loss on the network, which is a more realistic and useful figure). I think tracking packet loss over periods of say a second might be more useful and accurate.

We decided to go this route as RNSM actually allow you to configure over how many samples and how long you want the packet loss to be. Since this is used by the tools, it's an easy way to get the value and leave in the end of the user how much precision and flexibility they want.